home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000053_icon-group-sender _Thu Apr 29 14:17:49 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 3 May 1993 12:47:51 MST
  2. Date: 29 Apr 93 14:17:49 GMT
  3. From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU  (Richard L. Goerwitz)
  4. Organization: University of Chicago
  5. Subject: Re: runtime debugger and the Icon fan club.
  6. Message-Id: <1993Apr29.141749.24949@midway.uchicago.edu>
  7. References: <9304281927.AA17778@roll.csd.sgi.com>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. mitch@roll.csd.sgi.com (Tom Mitchell) makes some interesting comments
  14. on a posting of mine:
  15.  
  16. >|does not cater to the introductory CS course regimen.  Icon has, as its
  17. >|natural constituency, people interested in AI, NLP, text, translation,
  18. >|and general nonnumeric computing.
  19. >
  20. >I wonder, since Icon is implemented in 'C' it might be considered 
  21. >dependent on 'C' and thus less interesting.  Also given that there
  22. >is also a strong bias toward stronger type defines in ANSI 'C',
  23. >the lack of type checking in Icon could be seen as a loss 
  24. >against the curriculum goals.
  25.  
  26. Actually, if you think deeply about it, you'll notice that Icon has
  27. more extensive type checking than most other languages.  It is a very
  28. strongly typed language.  This does not mean, however, that it is
  29. statically typed.  If strong/dynamic typing is seen as a deficit (and
  30. I believe you that it is), then this is very odd, since in fact a great
  31. many higher-level languages use similar schemes.
  32.  
  33. The way Icon works is this:  Objects of any type can be assigned to a
  34. variable.  The language always knows what type data object that variable
  35. reflects at any given time.  The variable, however, may be assigned a
  36. new object of any type, though.  In this case, Icon still knows what
  37. type the variable is, and it knows (moreover) whether to garbage-collect
  38. the old object.  Described in this way, Icon hardly differs from LISP,
  39. which is used by many CS instructors as a first programming language
  40. instead of Pascal (and rightly so, since it allows one to move rapidly
  41. into the conceptual foundations of programming).
  42.  
  43. >Just in case should some one sets out to do this. An
  44. >irritant to me is little inconsistent 'features' like {} and ; 
  45. >omissions where the parser can permit such things to be
  46. >omitted in one place and not in others.
  47.  
  48. I am not sure what you're talking about when it comes to {}, except
  49. in the sense that {} can always be used to group a code block, just
  50. as in C.  Automatic semicolon insertion is also an interesting issue.  Most
  51. inveterate Icon programmers find it silly to have to insert a semicolon
  52. after every line.  We mainly use the semicolon to separate two expres-
  53. sions abutted on the same line.  Generally it is lacking from idiomatic
  54. Icon code, and with good reason:  It is generally superfluous even in
  55. languages that force one to use it!
  56.  
  57. >Sort of a summary:
  58. >
  59. >Does Icon support these goals in the first two years of a CS
  60. >education?  Mostly not I suspect.
  61.  
  62. What are introductory CS goals?  I'd say they are:  1) getting a basic
  63. grasp of control flow, 2) learning about basic data structures, and 3)
  64. getting some hands-on, practical experience cutting code.  Good stu-
  65. dents should be exposed to several styles of programming, and language
  66. paradigms.  They need not actually study them (and in fact probably
  67. should not at this level), but students should have explained to them
  68. about 1) classic languages like LISP, 2) non-imperative, backtracking
  69. languages like Prolog, 3) standard data structures, control-flow, and
  70. scoping mechanisms found in Algol-family languages, and 4) object-ori-
  71. ented programming languages and/or techniques.
  72.  
  73. My problem is that I had to learn all of this stuff on my own, being a
  74. humanities student.  It is misery and agony trying to exist in a world
  75. where introductory programming to most people means learning about fac-
  76. toring and sorting algorithms in a cut-down language like Pascal.  For
  77. a humanities student, these sorts of things are largely irrelevant, or
  78. at least not relevant at the introductory level.
  79.  
  80. >What are the curriculum goals of a CS education?  What are
  81. >the education goals of a non CS education.
  82.  
  83. For a humanities programmer the goals are exactly the same as for a CS
  84. programmer.  The only difference is that the actual content of 3 above.
  85. At least this has been my *personal* experience.
  86.  
  87. >Does Icon support the CS needs of a non-CS education?
  88.  
  89. I can't honestly say I know until I've had the chance to teach a few
  90. introductory humanities programming courses, which I doubt I'll get to
  91. do, seeing as my degree is in Near Eastern Languages & Civilizations :-).
  92.  
  93. Interesting comments you make, though.
  94.  
  95. -- 
  96.  
  97.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  98.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  99.